Embodiments of the present invention relate generally to configuration and management of distributed computer systems, and more particularly to use and analysis of policies applied to both web service clients and web services in such systems.
Information technology provides automated systems to meet the needs of organizations, but factors such as the complexity of the systems, changing markets, increasing competitive pressures, and evolving customer needs are creating demand for more flexible and efficient systems. Enterprise applications can be structured as web service clients that invoke web services via the Internet or other communications network via defined interfaces. A component that provides an element of functionality, such as executing a transaction, computing a value, storing information in a database, and other operations, can be provided in the form of a web service, which has a defined input service interface of one or more operations and associated input parameters, and, ordinarily, a defined reference interface of operations that the web service invokes, e.g., to delegate tasks to other web services. The reference interface corresponds to the service interface of the web service to be invoked. These invocations can be performed by, for example, sending messages via a computer network from an invoking service or application to the referenced service. Service Oriented Architectures (SOA) provide frameworks and conventions for creating applications using this service-oriented architecture.
SOA facilitates the development of enterprise applications as modular web services that can be easily integrated and reused. SOA defines how the services interact, so that different applications can be integrated. Applications can communicate with the services via Web protocols such as HTTP. SOA defines service interfaces in terms of protocols and features. Clients (i.e., applications) can invoke services by exchanging messages, e.g., a request message from the application to a server that implements the service, and a response message from the server back to the application after executing the service. Services can also be invoked by other services. Messages can be sent and received via channels, e.g., network connections. A “binding” establishes the connection between an SOA composite application and the external world. There are two types of binding components: services, which provide the outside world with an entry point to the SOA composite application and describe the protocols that can communicate with the service (for example, SOAP/HTTP or a JCA adapter), and references, which enable messages to be sent from the SOA composite application to external services in the outside world. Services use “endpoints” to access the channels and send/receive messages. An endpoint is an association between a binding and a network address that may be used to communicate with a service. Thus an endpoint indicates a specific address for accessing a service using a specific protocol and data format.
Each service provides an operation, such as a bank account deposit. An application or another service calls an appropriate Application Programming Interface (API) function of the SOA system to invoke the service by passing messages according to the protocol for accessing the service. This process of invoking a service is also referred to herein as “invocation” of the service. Data can be included in the invocation message in accordance with a data format specified by metadata associated with the binding. SOA provides features for specifying desired “quality of service” parameters that applications and services are to adhere to when invoking services and processing service invocations, respectively. One type of quality of service is security, which includes user authentication, data encryption, authorization of users to perform particular operations, and the like. Security-related parameters, such as details of how security is to be implemented, e.g., which type of authentication and encryption to use, can be specified by system users or administrators as “security policies” that can be attached to or associated with service input interfaces and reference interfaces. A security policy can be understood as a data item that includes a specific value for a parameter, e.g., the name of a specific type of encryption. When a security policy is attached to a service, the service can implement security features in accordance with the parameters specified in the policy. Thus, application developers can provide flexible security features by implementing security with reference to policies that can be supplied later, e.g., when the application is deployed for use by a customer, or when the customer's security needs change. The customer can then provide specific policies to configure the security features, e.g., by specifying a particular type of encryption with a particular level of security. The customer associates a security policy with each security-sensitive service using an administrative tool, such as a graphical user interface. When security requirements change, the customer can change the policies accordingly. Other types of quality of service configuration can be performed similarly.
For example, the quality of service of network communication may be configurable between higher-quality settings that have slower performance and lower-quality settings that are faster. A network protocol quality of service parameter can be provided by the application, and a customer who deploys the application can specify a particular setting for the quality of service, e.g., reliable or guaranteed, by attaching a policy that specifies the particular setting to the services in the application.
SOA applications can be implemented using “orchestration” to compose “composite” applications that invoke services. In one example, Business Process Execution Language (“BPEL”) is a standardized representation of processes, and the SOA system provides a process engine or manager that enables users to design and execute BPEL processes that invoke the services. The details of the application and services, and the formats of the data that is exchanged, e.g., between different BPEL processes in a composite application, are described by metadata associated with corresponding portions of the services and applications, such as data types associated with bindings.